As is known in the art, mobile application software (also sometimes referred to as a “mobile application” or more simply a “mobile app”) is a computer program designed to execute on a mobile processing platform such as a smart phone, tablet computer or other mobile devices. In a setting in which a mobile application executing on a mobile device is used within the context of an organization, the mobile application is typically connected to resources of the organization (e.g. organization databases) through a wireless network.
One concern for designers of mobile applications is how such an application operates when “disconnected from” (i.e. is without access to) the network. This problem is particularly acute for mobile applications (e.g. mobile business applications) in which multiple users operate on common data records (e.g. such as might be stored in a database) and transactional semantics must be enforced to ensure data integrity in the database. Current solutions require complex logic to be added in a custom, per-application manner thereby making it relatively expensive (and in some cases prohibitively expensive) for businesses to develop new, or transition existing, internal applications to mobile devices.
As demand for mobile applications has increased, enterprises are now confronted with how they will start taking advantage of mobile devices for internal use. There are large corporations that have hundreds, thousands, and even tens of thousands of Microsoft Access applications in use, targeted at non-mobile devices, and having minimal (or no) web support. In-house developers, often in the best position to understand employee needs, may be comfortable with environments like PHP, Microsoft Access, Visual Basic, Filemaker, etc., however they may not be skilled in the latest computer languages and techniques, such as mobile applications built using Objective-C, Java for Android, or even HTML5 and JavaScript. Outsourcing mobile application development is often cost-prohibitive to small and medium-sized businesses.
One factor that appears to be slowing the development and deployment of mobile business application software is the need to support frequent or intermittent offline operation. Unlike traditional browser-based business application software, which is generally always connected to a shared database (perhaps via an application server), mobile applications frequently have to operate without a network connection and without the ability to immediately update or query the database. Network connections may not be available for a number of reasons including, for example, dropped connections in cellular networks or a device being located outside the cellular network coverage area (i.e., within a “dead zone”).
Corporate software developers are finding that a significant percentage of mobile applications require offline operation at least some of the time. Several issues arise in the development of such applications. For example, when a user makes changes to records stored in a database to which the user is connected through the mobile application, those changes must be preserved until they can be synchronized with the database. This includes being able to maintain changes through interruptions in running the mobile application (such as making a phone call, consulting a mapping app, or showing a presentation to a customer), as well as situations such as the mobile device losing power (e.g. due to battery discharge). The time between a user making a change and the change being synchronized to the database is potentially very long.
A common strategy for synchronizing data is to keep a replica of the database system on the mobile device. The application can then be written in the same manner as it would be if it was connected to a shared database over a constant network connection, but instead use the local database. Other software, part of the local and shared databases, takes care of automatically synchronizing the contents of the two at those times when a connection does exist. Most of the code needed to do the synchronization is separate from the application and need not be of much concern to the mobile application developer. The same syncing database may be able to be used for multiple applications, depending upon the deployment system. An issue, though, is that the local database may need to have additional information about the data it is maintaining so that it can validate new data being stored and communicate validation errors back to the mobile application at the time of data entry. Another issue with using an intermediate database arises when the database is in a different form than the corporate database. It would be necessary to provide additional intermediate code on the server (or between servers) to synchronize the database that connects to the client with the backend corporate database.
A different strategy for dealing with disconnected operation is to have the mobile application itself keep track of database operations, such as creating or updating records; this strategy is referred to herein as “deferred updating.” When data is needed from the database, or an operation is to be committed to the database, and if the connection is active, the database is accessed through the connection to the server and things work normally. If the connection is not active, then the application makes use of data that it has cached from the server and the application keeps track of changes to be made, queuing those changes up for future connections to the server. When the connection becomes active again, the deferred changes are sent to update the database through the server, and new data is downloaded if needed.